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REMARKS/ARGUMENTS 

By this amendment, Claims 1, 17, 49 and 50 are amended and Claims 51-56 are added. 
No Claims have been canceled. No new matter has been added. Therefore, Claims 1-2, 5-10, 
13-28, 30-44 and 46-56 are pending in the application. 

Support for the amendments to Claim 1 can be found throughout Applicants' 
specification including, for example, in paragraphs [0045]-[0048]. 

Support for new Claims 52 and 54 can also be found throughout Applicants' Specification 
including, for example, in paragraph [0047], 

New Claims 55 and 56 correspond respectively to previously canceled Claims 3 and 11. 

Each issued raised in the Office Action mailed December 8, 2008 ("Office Action") is 
addressed hereinafter. 

CLAIM REJECTIONS - 35 U.S.C. § 102 

Claims 1-2, 5-10, 13-28, and 30-44 and 46-50 were rejected under 35 U.S.C. § 102(e) as 
allegedly anticipated by U.S. Pat. Pub. No. 2002/0156685 ("Ehrlich"). Applicants respectfully 
traverse. 

To anticipate a claim of the present application, Ehrlich must teach or reasonably suggest 
"each and every element" of the claim "in as complete detail as is contained in the claim". 
(MPEP § 2131) Further, while the claim may be given its "broadest reasonable interpretation" 
for the purposes of making an anticipation determination, the interpretation must be "consistent 
with the specification" and must be "consistent with the interpretation those skilled in the art 
would reach." (MPEP § 21 1 1) 

CLAIM 1 
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Present Claim 1 as amended recites: 

1 . A method for handling requests for web services, the method comprising the computer- 
implemented steps of: 

receiving at a web services broker, from a particular instance of a client application, a 
request for information, wherein said request includes an identification of a 
particular web service from which said particular instance wants said requested 
information, the request having first input data, the first input data being in a 
form that cannot be used by said particular web service to service requests 
for said information, the first input data including a value that corresponds to a 
parameter required by the particular web service; 

wherein the particular web service serves as the source of said requested information, and 
is separate from the web services broker; 

wherein the particular instance of said client application is separate from the web services 
broker; 

in response to receiving said request, the web services broker 

accessing, based on said identification of said particular web service, 
transformation information that specifies, 

how to transform said first input data associated with said request to 
second input data that said particular web service can use to 
service requests for said requested information, and 

how to invoke said particular web service in a manner required by said 
particular web service, to obtain said requested information from 
said particular web service; 
transforming said first input data to said second input data, wherein 

transforming the first input data includes changing said value, based 
on said transformation information, to create a changed value; and 
invoking, in said manner required by said particular web service, said particular 
web service to obtain said requested information from said particular web 
service; 

wherein said requested information is obtained from said particular web 

service by providing the changed value to the particular web service 
as a value for said parameter. 



Applicants respectfully submit that at least the above-bolded features of Claim 1 are not 
taught or in any way suggested by Ehrlich. 

In the Advisory Action mailed February 26, 2009, the Examiner asserts that Ehrlich 
satisfies the "transforming said first input data to said second input data" feature of Claim 1. 
Applicants respectfully disagree. However, to expedite allowance of the claims of the subject 
application, Claim 1 has been amended herein to resolve any potential ambiguity of previously 
presented Claim 1 . For example, Claim 1 now makes clear that the "first input data" included in 
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the request from the particular instance of the client application includes "a value that 
corresponds to a parameter required by the particular web service". The web services broker, in 
response to receiving the request, transforms the first input data including "changing said value, 
based on said transformation information, to create a changed value." The "requested 
information" is obtained "by providing the changed value to the particular web service as a value 
for said parameter." 

The method of Claim 1 may be useful, for example, to allow a first team of engineers to 
develop and deploy the particular instance of a client application without concern to what form 
the particular web service expects input data to be in. An entirely different team of engineers, at 
a later time, could then deploy the web services broker along with transformation information 
that brokers requests from the particular instance of the client application to the particular web 
service. Specifically, since the web services broker is not in control of how the client application 
forms the input data included in requests, the web services broker provides transformation 
information that specifies how to transform input data associated with a request to produce 
transformed input data that can be used by the particular web service to provide the requested 
information to the particular instance of the client application. The method of Claim 1 is not 
taught or in any rendered obvious by Ehrlich. 



EHRLICH'S VIRTUAL SHOPPING CART SYSTEM 
In contrast to the web services broker of Claim 1, Ehrlich' s shopping system is in control 
of the form of the input data provided by users of the shopping system. For example, Ehrlich 's 
shopping system provides a user interface that allows a user to search for purchase items, add 
items to a virtual shopping cart, and submit a purchase request for items added to the shopping 
cart. Since Ehrlich 's shopping system provides the interface by which a user submits purchase 
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requests to the shopping system, Ehrlich's shopping system is in control of the form of the input 
data included in the requests. 

Not surprisingly then, Ehrlich's virtual shopping system does not describe the claimed 
"transformation information" that specifies "how to transform said first input data associated 
with said request to second input data that said particular web service can use to service requests 
for said requested information", as featured in Claim 1. Ehrlich does describe a "protocol 
broker" that "chooses for each purchase request, the most appropriate protocol and 
communication mode " for communicating with a merchant site. (Ehrlich, [0080]) For 
example, the protocol broker may choose to communicate with a merchant site using the 
Hypertext Transfer Protocol (HTTP) or the Simple Object Access Protocol (SOAP). (Id.) 
However, Claim 1 is not just about transformation information that specifies the protocol for a 
particular web service. Claim 1 expressly requires transformation information that specifies 
"how to transform" input data provided in a request. In other words, picking the form of 
delivery of a message is entirely different from transforming content in the message itself. 

In rejecting Claim 1, the Office Action appears to equate the "communication schema" of 
Ehrlich with the claimed "transformation information" for "transforming said first input data to 
said second input data", as featured in Claim 1. Ehrlich describes creating a "communication 
schema" for each merchant that indicates "the required protocol" and "has place holders for the 
item ID, session ID, etc." (Ehrlich, [0088]) "During the purchase request, the protocol broker 
replaces the place holders with the actual values or items required by the merchant. . ." (Id.) 
However, replacing place holders is entirely different from transforming input data from a form 
that cannot be used by a merchant into input data that can be used by the merchant. Replacing 
place holders is entirely different because the input data in Ehrlich's purchase request that is 
provided to the merchant does not change forms as a result of replacing the place holders. For 
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example, the values for <Title> and <ISDN> in the example purchase request described in 
paragraphs [0101]-[01 12] of Ehrlich, if provided to a merchant, would not be transformed by 
Ehrlich's protocol broker. Rather, the protocol broker would simply replace the appropriate 
place holders in the communication schema for the merchant with values in the same form as 
included in the purchase request. 

Further, since Ehrlich does not describe transforming input data from a form that cannot 
be used by a merchant into a form that can be used by merchant, Ehrlich cannot possibly teach or 
suggest "changing said value, based on said transformation information, to create a changed 
value", as featured in Claim 1. Ehrlich'?, protocol broker does not in any way alter, transform, or 
change values in a purchase request that correspond to parameters required by a merchant. 
Instead, as explained above, Ehrlich's protocol broker merely substitutes place holders with 
values from a purchase request that correspond to parameters required by a merchant. This is not 
the same as "changing said value, based on said transformation information, to create a changed 
value", as featured in Claim 1 because substituting a place holder with a value does not change 
the value to create a changed value. 

Indeed, given that the Ehrlich 's shopping system is in control of the form of the purchase 
request from the shopper, one skilled in the art would conclude that the input data in a purchase 
request is in a form that the merchant site can use. Further, the disclosure of Ehrlich would lead 
a skilled artisan to conclude that, to the extent that Ehrlich's shopping system transforms a 
purchase request, it does so only with respect to the protocol used to convey the purchase request 
to a merchant, and not with respect to input data required as a parameter by the merchant. For 
example, Ehrlich states at paragraph [0079]: 

[0079] With reference to FIG. 3B, and at step 375, the shopping coordinator 100 creates a purchase request for each item of the virtual 
shopping cart and forwards these requests to the protocol broker 105 using, for example, SOAP as the communication protocol. To 
proceed with the purchase of items in the virtual shopping cart, the protocol broker 105 communicates with each merchant web site 
represented in FIG. 2, for example, as merchant site A (180) and merchant site B (185), by using the merchant's preferred protocol. 
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Each merchant might use a different protocol such as HTTP, SMTP, or SOAP. Therefore, the protocol broker 105 translates the 
SOAP protocol used by the shopping coordinator 100 into a purchase request that the merchant can understand. 

This cited portion of Ehrlich refers to a protocol broker translating the "protocol" of the 
purchase request but does not in any way teach or suggest changing values in the purchase 
request that correspond to parameters required by a merchant to produce changed values. One 
skilled in the art would conclude from this cited portion and Ehrlich as a whole, that Ehrlich' s 
protocol broker simply forwards values in a purchase request that correspond to parameters 
required by a merchant site - albeit using a different protocol - on to the merchant site without 
changing those values. Consequently, Applicants respectfully submit that Ehrlich does not teach 
or in way suggest "transforming said first input data to said second input data, wherein 
transforming the first input data includes changing said value, based on said transformation 
information, to create a changed value", as featured in Claim 1. 

Based on the foregoing, Applicants respectfully submit that Ehrlich does not teach or 
suggest each and every feature of Claim 1 in as complete detail as contained in Claim 1 . Claim 
49 recites similar features and is allowable over Ehrlich for the same reasons. 

CLAIM 2 

Claim 2 depends from Claim 1 and is therefore allowable over Ehrlich for the reasons 

given above with respect to Claim 1 . In addition, Claim 2 recites additional features that 

independently render Claim 2 patentable over Ehrlich. For example, Claim 2 recites: 

receiving, from said particular web service, said requested information; and 
transforming, based on said transformation information, said requested information to 
data that said client application can use. 

Thus, in Claim 2, the requested information received from the particular web service is 
transformed to data that the requesting client application can use. 
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With regard to Claim 2, the Advisory Action states "Ehrlich discloses Figure 2 where it 
teaches two-way communication and transformation between merchant 'a' and 'b'." However, 
while Ehrlich may describe two-way communication between the protocol broker and a 
merchant it does not teach or suggest two-way transformation as featured in Claim 2. 

Ehrlich describes only creating purchase requests that merchants can understand. 
Nothing in the cited portion of Ehrlich or elsewhere in Ehrlich describes the protocol broker 
transforming, based on accessed transformation information associated with a merchant, 
information received from the merchant site into data that user or shopper can use. In other 
words, Ehrlich describes only one-way transformations (requests from client to service) while 
Claim 2 is about two-way transformations (transformations of requests from client to web 
service and transformations of responses returned from the web service to the client). Thus, 
Claim 2 recites additional features that independently render Claim 2 patentable over Ehrlich. 

CLAIM 5 

Claim 5 recites: 

The method of Claim 1, wherein said transformation information includes a mapping of 
first input data from a first particular client application to second input data that a 
first web service can use, and a mapping of first input data from a second particular 
client application to said second input data that said first web service can use, and 
wherein said first input data from said first particular client application has a different 
form than said first input data from said second particular client application. (Emphasis 
added.) 

Claim 5 is about a many-to-one transformation. In particular, Claim 5 features 
transformation information for mapping, to the same "second input data", input data from two 
clients, where the form of the input data from one client is different from the form of the input 
data from the other client. In contrast, in Ehrlich, purchase requests for a particular item from a 
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particular merchant will have the same form (i.e., the form will not vary from client to client). 
For example, using an example provided in Ehrlich, the form of the input data in the purchase 
request for the book titled "Professional Active Server Pages 3.0" described in paragraphs 
[0101]-[01 12] of Ehrlich would be same regardless of which user or shopper submitted the 
purchase request. Thus, it would not make sense for Ehrlich's protocol broker to use 
transformation information like the transformation information featured in Claim 5 that maps, to 
the same "second input data", input data from two clients, where the form of the input data from 
one client is different from the form of the input data from the other client. Consequently, 
Applicants respectfully submit that Claim 5 recites additional features that independently render 
Claim 5 patentable over Ehrlich. 



CLAIM 17 



Claim 17 recites: 

17. A method for handling requests for web services, the method comprising the computer- 
implemented steps of: 

receiving at a web services broker, from a particular instance of a client application, a 
request for information, wherein said request includes an identification of a 
particular instance of said client application, the request having first input 
data, the first input data being in a form that cannot be used by a particular 
web service to service requests for said information, the first input data 
including a value that corresponds to an input parameter required by the particular 
web service; 

wherein the particular web service serves as the source of said requested information and 
is separate from the web services broker; 

wherein the client application is separate from the web services broker; 

in response to receiving said request, based on said identification of said particular 
instance of said client application, the web services broker accessing 
transformation information; 

wherein said transformation information includes a mapping between said 

identification of said particular instance of said client application and an 
identification of said particular web service, the mapping indicating that said 
particular instance prefers said particular web service to service requests 
from said particular instance for said requested information; 
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wherein said transformation information specifies how to transform said first input 
data associated with said request to second input data that said particular 
web service can use to service requests for said requested information; 

based on said transformation information, the web services broker transforming 

said first input data to said second input data, wherein transforming the first 
input data includes changing said value, based on said transformation 
information, to create a changed value; 

the web services broker invoking, in said manner required by said particular web service, 
said particular web seivice to obtain said requested information from said 
particular web seivice; 

wherein said requested information is obtained from said particular web service by 
the web services broker providing the changed value to the particular web 
service as a value for said input parameter. 

Applicants respectfully submit that at least the above-bolded features of Claim 17 are not 
taught or in any way suggested by Ehrlich. 

The Office Action contends that Ehrlich 's "merchant protocol data" is equivalent to the 
transformation information of Claim 17. {See Office Action, page 6). However, the merchant 
protocol data of Ehrlich corresponds to the merchant specified in the purchase request and not 
any sort of identification of the particular instance of the client application making the 
purchase request. For example, paragraph [0113] of Ehrlich states with respect to an example 
purchase request "[t]he protocol broker analyzes and parses the SOAP purchase request, retrieves 
the merchant protocol data for AlBooks.com from the merchant schema database 120. 
(Emphasis added.) In this example, "AlBooks.com" identifies the merchant, not the particular 
instance of the client application that sent the purchase request. In contrast, Claim 17 expressly 
requires that the "in response to receiving said request, based on said identification of said 
particular instance of said client application , the web services broker accessing transformation 
information". 

Furthermore, Claim 17 expressly requires that the claimed "transformation information" 
include " a mapping between said identification of said particular instance of said client 
application and an identification of said particular web service, the mapping indicating that said 
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particular instance prefers said particular web service to service requests from said particular 

instance for said requested information." Ehrlich's merchant protocol data does not contain any 

sort of mapping between an identification of a particular instance of a client application and a 

preferred merchant. Consequently, Ehrlich also does not teach or suggest "wherein said 

transformation information includes a mapping between said identification of said particular 

instance of said client application and an identification of said particular web service, the 

mapping indicating that said particular instance prefers said particular web service to service 

requests from said particular instance for said requested information", as featured in Claim 17. 

Additionally, the following bolded features of Claim 17 are similar to features recited in 

Claim 1 discussed above 

receiving at a web services broker, from a particular instance of a client application, a 
request for information, wherein said request includes an identification of a 
particular instance of said client application, the request having first input data, 
the first input data being in a form that cannot be used by a particular web 
service to service requests for said information, the first input data including a 
value that corresponds to an input parameter required by the particular web 
service; 

wherein the particular web service serves as the source of said requested information and 

is separate from the web services broker; 
wherein the client application is separate from the web services broker; 
in response to receiving said request, based on said identification of said particular 

instance of said client application, the web services broker accessing 

transformation information; 
wherein said transformation information includes a mapping between said identification 

of said particular instance of said client application and an identification of said 

particular web service, the mapping indicating that said particular instance prefers 

said particular web service to service requests from said particular instance for 

said requested information; 
wherein said transformation information specifies how to transform said first input data 

associated with said request to second input data that said particular web service 

can use to service requests for said requested information; 
based on said transformation information, the web services broker transforming 

said first input data to said second input data, wherein transforming the first 

input data includes changing said value, based on said transformation 

information, to create a changed value; 
the web services broker invoking said particular web service to obtain said requested 

information from said particular web service; 
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wherein said requested information is obtained from said particular web service by 
the web services broker providing the changed value to the particular web 
service as a value for said input parameter. 

For the reasons given above with respect to Claim 1, Applicants respectfully submit that 
Ehrlich also does not satisfy the above-bolded features of Claim 17. 

Based on the foregoing, Applicants respectfully submit that Ehrlich does not teach or 
suggest each and every feature of Claim 17. Claim 50 recites similar features and is allowable 
over Ehrlich for the same reasons. 

REMAINING CLAIMS 
The pending claims not discussed so far are dependant claims that depend on an 
independent claim that is discussed above. Because each dependant claim includes the features 
of claims upon which they depend, the dependant claims are patentable for at least those reasons 
the claims upon which the dependant claims depend are patentable. Removal of the rejections 
with respect to the dependant claims and allowance of the dependant claims is respectfully 
requested. In addition, the dependent claims introduce additional features that independently 
render them patentable. Due to the fundamental differences already identified, a separate 
discussion of those features is not included at this time. 
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CONCLUSION 

For the reasons set forth above, it is respectfully submitted that all of the pending claims 
are now in condition for allowance. Therefore, the issuance of a formal Notice of Allowance is 
believed next in order, and that action is most earnestly solicited. 

The Examiner is respectfully requested to contact the undersigned by telephone if it is 
believed that such contact would further the examination of the present application. 

Please charge any shortages or credit any overages to Deposit Account No. 50-1302. 

Respectfully submitted, 

Hickman Palermo Truong & Becker LLP 

Date: March 16, 2009 /AdamCStone#60531/ 

Adam Christopher Stone 
Reg. No. 60,531 

2055 Gateway Place, Suite 550 
San Jose, California 95110-1089 
Telephone No.: (408) 414-1080 ext. 231 
Facsimile No.: (408) 414-1076 
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